In most cases, refactoring legacy code — particularly someone else's work — involves adapting to the multitude of styles and errors that you will discover upon reviewing the code. Your primary responsibility is to leave the place better than when you arrived.
It’s essential to take a sensible approach to the code upgrade. Although programming has set rules (depending on the paradigm followed), those of us who are coders know that coding can sometimes also be an art. We take pride in our work and seek perfection in it.
Unfortunately, when upgrading code, perfection is not always feasible. And successful code-upgrade project leaders must keep this in mind to be successful.
Code Ownership
The first major myth of revising legacy code is believing you own someone else’s code. The challenge is that you may think the code is bad and whoever wrote it didn’t know what they were doing, or that you could have done a better job.
This is a method of thinking that the code upgrader cannot afford to have.
As programmers, we are taught what we believe is the “right way” to code. We are taught this almost religiously. OOP coders are indoctrinated into believing that only a fully object-oriented model with the highest degree of abstraction is the “correct” way to code and that any other coding paradigm is inferior.
They are taught that this OOP method might be “slow in the beginning but pays off in the end.”
That statement cannot be considered correct all of the time. For example, in tiny software development houses where budgets are tight and client requirements are usually small, a long runway to develop something that follows all the principles of OOP might mean not getting the deal — it would simply be too expensive for the client.
End-users don’t care about coding paradigms. They just care if the software works.
As programmers taking on legacy code, it’s important that we don’t adopt a puritanical and super-critical approach to the code that was written by someone else.
Sure, maybe we would have written it differently. But the main question to ask is, does the code work in its current form?
Particularly in small software houses, the rules to “coding correctly” often get broken. This happens most often when the coder is also close to the management team. Because the stringent structure of senior programmer, software analyst, project leader, etc. is not in place, the coder might tend to think in terms of the company’s budget and just “fix something quickly and easily” in order to keep the client happy, rather than take all the necessary steps to make the code “correct.”
This is not necessarily incorrect in those circumstances.
Sure, one of the beauties of coding according to standards is that any programmer can pick up any project and, provided the documentation is up to date, can start coding as quickly as possible. But, again, this depends on the circumstances of the software and how much of an employee turnover that company has.
So, try to develop a sense of understanding and appreciation for what was written, and why it was written that way. Failing to do this, you might end up wanting to “rewrite everything because it is horribly written!” But that only means lots of additional work and a budget that might be too high for the client.
Why does the code need to be updated?
It’s crucial to ask why the code needs to be updated. To change and refactor code simply to make it “conform to all the right rules” is dogmatic and expensive.
As the old saying goes, If it ain’t broke, don’t fix it!
A good place to start is to consider a margin for improvement, not necessarily trying to upgrade the whole lot in one shot.
Two of the main reasons why legacy code might need to be updated are:
- The old code does not integrate well with new modules and features, so needs to be brought up to scratch.
- The software is slow and newer code would make it significantly faster.
Test, then proceed step by step
One way to understand the purpose of the legacy code is to create characterisation tests and unit tests. You can also run a static analyser over your code to identify potential problems.
Reviewing the documentation of the original requirements for that piece of software can also help you understand where the code came from, and why it was written the way it was.
Your time is valuable. Only rewrite code when absolutely necessary. Start with the deepest point of the code and refactor it as needed. And always have a safety net so you can revert to a previous version.
Upgrading legacy code can be a terrifying task! This is especially true when the code that needs to be upgraded is enormous.
The stories about how this has been done in large companies are sometimes epic indeed, like the story about how Dropbox had to modify its code-base to move away from Amazon’s cloud services.
Their particular situation was made more difficult by the fact that they had so many active users!
Again, each project is unique and has its own particularities. Making major changes to a live platform like that could have had catastrophic results.
But, no matter how large a codebase is, the best way to change that codebase is step by step. This reduces the fear factor in fellow programmers and builds up confidence in the project as the code is slowly improved.
Test each change thoroughly and only proceed onto the next major change when those tests have been proven out.
Get a Code Review By Thorgate
We have been upgrading code for many years, following an agile approach to our coding, allowing for smooth code upgrades at the optimum budget for our clients.
As mentioned above, every project is unique. But we believe strongly in upgrading step by step, upgrading only what is essential, and working in full cooperation and communication with the client to ensure that the resultant upgrade has the maximum possible value to them.
To learn more about getting a review of your legacy code by Thorgate, feel free to write to us directly at hi@thorgate.eu
Read related articles:
The 2022 Approach to Writing Code
